
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <title>Security Risk Assessment &#8212; PSA Crypto API 1.1.0 documentation</title>
    <link rel="stylesheet" href="../_static/alabaster.css" type="text/css" />
    <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
    <script type="text/javascript">
      var DOCUMENTATION_OPTIONS = {
        URL_ROOT:    '../',
        VERSION:     '1.1.0',
        COLLAPSE_INDEX: false,
        FILE_SUFFIX: '.html',
        HAS_SOURCE:  false,
        SOURCELINK_SUFFIX: '.txt'
      };
    </script>
    <script type="text/javascript" src="../_static/jquery.js"></script>
    <script type="text/javascript" src="../_static/underscore.js"></script>
    <script type="text/javascript" src="../_static/doctools.js"></script>
    <link rel="author" title="About these documents" href="../about.html" />
    <link rel="index" title="Index" href="../genindex.html" />
    <link rel="search" title="Search" href="../search.html" />
    <link rel="next" title="Changes to the API" href="history.html" />
    <link rel="prev" title="Example macro implementations" href="specdef_values.html" />
   
  <link rel="stylesheet" href="../_static/custom.css" type="text/css" />
  
  <meta name="viewport" content="width=device-width, initial-scale=0.9, maximum-scale=0.9" />

  </head>
  <body>
  

    <div class="document">
      <div class="documentwrapper">
        <div class="bodywrapper">
          <div class="body" role="main">
            
  <div class="section" id="security-risk-assessment">
<span id="sra"></span><h1>Security Risk Assessment</h1>
<p>This Security Risk Assessment (SRA) analyses the security of the PSA Cryptography API itself, not of any specific implementation of the API, or any specific use of the API. However, the security of an implementation of this API depends on the implementation design, the capabilities of the system in which it is deployed, and the need to address some of the threats identified in this assessment.</p>
<p>To enable this API to be suitable for a wider range of security use cases, this SRA considers a broad range of adversarial models and threats to the application and the implementation, as well as to the API.</p>
<p>This approach allows the assessment to identify API design requirements that affect the ability for an implementation to mitigate threats that do not directly attack the API.</p>
<p>The scope is described in <a class="reference internal" href="#adversarial-models"><span class="secref">Adversarial models</span></a>.</p>
<div class="section" id="architecture">
<h2>Architecture</h2>
<div class="section" id="system-definition">
<h3>System definition</h3>
<p><span><a class="reference internal" href="#fig-system-entities"><span class="numref">Figure 18</span></a></span> shows the PSA Cryptography API as the defined interface that an Application uses to interact with the Cryptoprocessor.</p>
<div class="figure" id="fig-system-entities">
<img alt="../_images/system-entities.svg" src="../_images/system-entities.svg" /><p class="caption"><span class="caption-number">Figure 18 </span><span class="caption-text">PSA Cryptography API</span></p>
</div>
<div class="section" id="assumptions-constraints-and-interacting-entities">
<h4>Assumptions, constraints, and interacting entities</h4>
<p>This SRA makes the following assumptions about the PSA Cryptography API design:</p>
<ul class="simple">
<li>The API does not provide arguments that identify the caller, because they can be spoofed easily, and cannot be relied upon. It is assumed that the implementation of the API can determine the caller identity, where this is required. See <a class="reference internal" href="../overview/goals.html#isolation"><span class="secref">Optional isolation</span></a>.</li>
<li>The API should not prevent the use of mitigations that are required by an implementation of the API. See <a class="reference internal" href="#remediation"><span class="secref">Remediation &amp; residual risk</span></a>.</li>
<li>The API follows best-practices for C interface design, reducing the risk of exploitable errors in the application and implementation code. See <a class="reference internal" href="../overview/goals.html#usability"><span class="secref">Ease of use</span></a>.</li>
</ul>
</div>
<div class="section" id="trust-boundaries-and-information-flow">
<span id="dfd"></span><h4>Trust boundaries and information flow</h4>
<p>The PSA Cryptography API is the interface available to the programmer, and is the main attack surface that is analysed here. However, to ensure that the API enables the mitigation of other threats to an implementation, we also consider the system context in which the PSA Cryptography API is used.</p>
<p><span><a class="reference internal" href="#fig-dfd-no-isolation"><span class="numref">Figure 19</span></a></span> shows the data flow for a typical application usage of the PSA Cryptography API, for example, to exchange ciphertext with an external system, or for at rest protection in system non-volatile storage. The Application uses the PSA Cryptography API to interact with the Cryptoprocessor. The Cryptoprocessor stores persistent keys in a Key Store.</p>
<div class="figure" id="fig-dfd-no-isolation">
<img alt="../_images/dfd_no_isolation.svg" src="../_images/dfd_no_isolation.svg" /><p class="caption"><span class="caption-number">Figure 19 </span><span class="caption-text">PSA Cryptography API dataflow diagram for an implementation with no isolation</span></p>
</div>
<p>For some adversarial models, <a class="reference internal" href="../about.html#term-cryptoprocessor-isolation"><span class="term">Cryptoprocessor isolation</span></a> or <a class="reference internal" href="../about.html#term-caller-isolation"><span class="term">Caller isolation</span></a> is required in the implementation to achieve the security goals. See <a class="reference internal" href="#security-goals"><span class="secref">Security goals</span></a>, and remediations R.1 and R.2 in <a class="reference internal" href="#remediation"><span class="secref">Remediation &amp; residual risk</span></a>.</p>
<p>The Cryptoprocessor can optionally include a trust boundary within its implementation of the API. The trust boundary shown in <span><a class="reference internal" href="#fig-dfd-crypto-isolation"><span class="numref">Figure 20</span></a></span> corresponds to Cryptoprocessor isolation.</p>
<div class="figure" id="fig-dfd-crypto-isolation">
<img alt="../_images/dfd_crypto_isolation.svg" src="../_images/dfd_crypto_isolation.svg" /><p class="caption"><span class="caption-number">Figure 20 </span><span class="caption-text">PSA Cryptography API dataflow diagram for an implementation with cryptoprocessor isolation</span></p>
</div>
<p>If the implementation supports multiple, independent client Applications within the system, each Application has its own view of the Cryptoprocessor and key store. The additional trust boundaries for a caller isolated implementation are shown in <span><a class="reference internal" href="#fig-dfd-caller-isolation"><span class="numref">Figure 21</span></a></span>.</p>
<div class="figure" id="fig-dfd-caller-isolation">
<img alt="../_images/dfd_caller_isolation.svg" src="../_images/dfd_caller_isolation.svg" /><p class="caption"><span class="caption-number">Figure 21 </span><span class="caption-text">PSA Cryptography API dataflow diagram for an implementation with caller isolation</span></p>
</div>
</div>
</div>
<div class="section" id="assets-and-stakeholders">
<h3>Assets and stakeholders</h3>
<ol class="arabic">
<li><p class="first">Cryptographic keys and key-related assets. This includes the key properties, such as the key type, identity and policies.</p>
<p>Stakeholders can include the SiP, the OEM, the system or application owner. Owners of a key need to be able to use the key for cryptographic operations, such as encryption or signature, and where permitted, delete, copy or extract the key.</p>
<p>Disclosure of the cryptographic key material to an attacker defeats the protection that the use of cryptography provides. Modification of cryptographic key material or key properties by an attacker has the same end result. These allow an attacker access to the assets that are protected by the key.</p>
</li>
<li><p class="first">Other cryptographic assets, for example, intermediate calculation values and RNG state.</p>
<p>Disclosure or modification of these assets can enable recovery of cryptographic keys, and loss of cryptographic protection.</p>
</li>
<li><p class="first">Application input/output data and cryptographic operation state.</p>
<p>Application data is only provided to the Cryptoprocessor for cryptographic operations, and its stakeholder is the application owner.</p>
<p>Disclosure of this data — whether it is plaintext, or other data or state — to an attacker defeats the protection that the use of cryptography provides. Modification of this data can have the same effect.</p>
</li>
</ol>
</div>
<div class="section" id="security-goals">
<span id="id1"></span><h3>Security goals</h3>
<p>Using cryptography is a mitigation in response to the risk of disclosure or tampering with data assets that require protection, where isolation of the attacker from the data asset is unavailable or inadequate.</p>
<p>Using cryptography introduces other security threats. <span><a class="reference internal" href="#table-sg"><span class="numref">Table 24</span></a></span> lists the security goals for the PSA Cryptography API to address these threats.</p>
<table border="1" class="colwidths-given longtable docutils align-right" id="table-sg">
<caption><span class="caption-number">Table 24 </span><span class="caption-text">Security goals</span></caption>
<colgroup>
<col width="10%" />
<col width="90%" />
</colgroup>
<thead valign="bottom">
<tr class="row-odd"><th class="head">Id</th>
<th class="head">Description</th>
</tr>
</thead>
<tbody valign="top">
<tr class="row-even"><td>G.1</td>
<td>An attacker shall not be able to disclose the plaintext corresponding to a ciphertext for which they do not own the correct key.</td>
</tr>
<tr class="row-odd"><td>G.2</td>
<td>An attacker shall not be able to generate authenticated material for which they do not own the correct key.</td>
</tr>
<tr class="row-even"><td>G.3</td>
<td>An attacker shall not be able to exfiltrate keys or other private information stored by the PSA Cryptography API.</td>
</tr>
<tr class="row-odd"><td>G.4</td>
<td>An attacker shall not be able to alter any state held by the implementation of the PSA Cryptography API, such as internal keys or other private information (for example, certificates, signatures, etc.).</td>
</tr>
</tbody>
</table>
</div>
</div>
<div class="section" id="threat-model">
<h2>Threat Model</h2>
<div class="section" id="adversarial-models">
<span id="id2"></span><h3>Adversarial models</h3>
<p>The API itself has limited ability to mitigate threats. However, mitigation of some of the threats within the cryptoprocessor can place requirements on the API design. This analysis considers a broad attack surface, to also identify requirements that enable the mitigation of specific threats within a cryptoprocessor implementation.</p>
<p><span><a class="reference internal" href="#table-adversaries"><span class="numref">Table 25</span></a></span> describes the adversarial models that are considered in this assessment.</p>
<p>A specific implementation of the PSA Cryptography API might not include all of these attacker capabilities within its own threat model. In this case, the related threats, risks, and mitigations might not be required for that implementation.</p>
<table border="1" class="colwidths-given longtable docutils align-right" id="table-adversaries">
<caption><span class="caption-number">Table 25 </span><span class="caption-text">Adversarial models</span></caption>
<colgroup>
<col width="10%" />
<col width="90%" />
</colgroup>
<thead valign="bottom">
<tr class="row-odd"><th class="head">Id</th>
<th class="head">Description</th>
</tr>
</thead>
<tbody valign="top">
<tr class="row-even"><td>M.1</td>
<td>The Adversary is capable of accessing data that is outside the logical or physical boundaries of the system, such as messages in transit or data in storage. The adversary aims to compromise the security properties of this data, for example, revealing encrypted plaintext or injecting forged authenticated data.</td>
</tr>
<tr class="row-odd"><td>M.2</td>
<td><p class="first">The Adversary is capable of deploying and running software within the boundaries of the system with limited privileges, in order to compromise other parts of the system or gain access to protected assets.</p>
<p class="last">This includes the use of the PSA Cryptography API, mounting timing attacks, glitching by abusing exposed power control interfaces, and other attacks which are mounted exclusively by running uncompromised software.</p>
</td>
</tr>
<tr class="row-even"><td>M.3</td>
<td>The Adversary is capable of compromising a target application, in order to extract or manipulate data, or abuse the PSA Cryptography API from the application.</td>
</tr>
<tr class="row-odd"><td>M.4</td>
<td>The Adversary is capable of inducing faults or glitches during the application or cryptoprocessor operation.</td>
</tr>
<tr class="row-even"><td>M.5</td>
<td>The Adversary is capable of performing hardware-assisted side-channel analysis. For example, power analysis, or measurements of EM or photonic emissions.</td>
</tr>
</tbody>
</table>
<p>The following adversarial models are not considered in this assessment:</p>
<ul class="simple">
<li>The Adversary is capable of interposing the memory interface to observe and modify the memory contents.</li>
<li>The Adversary is capable of performing sophisticated hardware analysis and reverse engineering.</li>
</ul>
</div>
<div class="section" id="threats-and-attacks">
<h3>Threats and attacks</h3>
<p><span><a class="reference internal" href="#table-threats"><span class="numref">Table 26</span></a></span> describes threats to the Security Goals, and provides examples of corresponding attacks. This table identifies which Security goals are affected by the attacks, and which Adversarial model or models are required to execute the attack.</p>
<p>See <a class="reference internal" href="#risk-assessment"><span class="secref">Risk assessment</span></a> for an evaluation of the risks posed by these threats, <a class="reference internal" href="#mitigations"><span class="secref">Mitigations</span></a> for mitigation requirements in the API design, and <a class="reference internal" href="#remediation"><span class="secref">Remediation &amp; residual risk</span></a> for mitigation recommendations in the cryptoprocessor implementation.</p>
<table border="1" class="colwidths-given longtable docutils align-right" id="table-threats">
<caption><span class="caption-number">Table 26 </span><span class="caption-text">Threats and attacks</span></caption>
<colgroup>
<col width="8%" />
<col width="20%" />
<col width="8%" />
<col width="8%" />
<col width="56%" />
</colgroup>
<thead valign="bottom">
<tr class="row-odd"><th class="head">Threat</th>
<th class="head">&#160;</th>
<th class="head">&#160;</th>
<th class="head">&#160;</th>
<th class="head">Attack (Examples)</th>
</tr>
<tr class="row-even"><th class="head">Id</th>
<th class="head">Description</th>
<th class="head">Goals</th>
<th class="head">Models</th>
<th class="head">Id: Description</th>
</tr>
</thead>
<tbody valign="top">
<tr class="row-odd"><td>T.1</td>
<td>Use of insecure or incorrectly implemented cryptography</td>
<td>G.1 G.2</td>
<td>M.1</td>
<td><p class="first"><strong>A.C1</strong>: Using a cryptographic algorithm that is not adequately secure for the application use case can permit an attacker to recover the application plaintext from attacker-accessible data.</p>
<p><strong>A.C2</strong>: Using a cryptographic algorithm that is not adequately secure for the application use case can permit an attacker to inject forged authenticated material into application data in transit or in storage.</p>
<p class="last"><strong>A.C3</strong>: Using an insecure cryptographic algorithm, or one that is incorrectly implemented can permit an attacker to recover the cryptographic key. Key recovery enables the attacker to reveal encrypted plaintexts, and inject forged authenticated data.</p>
</td>
</tr>
<tr class="row-even"><td>T.2</td>
<td>Misuse of cryptographic algorithms</td>
<td>G.1 G.2</td>
<td>M.1</td>
<td><strong>A.C4</strong>: Reusing a cryptographic key with different algorithms can result in cryptanalysis attacks on the ciphertexts or signatures which enable an attacker to recover the plaintext, or the key itself.</td>
</tr>
<tr class="row-odd"><td>T.3</td>
<td>Recover non-extractable key through the API</td>
<td>G.3</td>
<td>M.2 or M.3</td>
<td><p class="first"><strong>A.C5</strong>: The attacker uses an indirect mechanism provided by the API to extract a key that is not intended to be extractable.</p>
<p class="last"><strong>A.C6</strong>: The attacker uses a mechanism provided by the API to enable brute-force recovery of a non-extractable key. For example, <span><em>On the Security of PKCS #11</em> <a class="reference internal" href="../about.html#citation-clulow"><span class="cite">[CLULOW]</span></a></span> describes various flaws in the design of the PKCS #11 interface standard that enable an attacker to recover secret and non-extractable keys.</p>
</td>
</tr>
<tr class="row-even"><td>T.4</td>
<td>Illegal inputs to the API</td>
<td>G.3 G.4</td>
<td>M.2 or M.3</td>
<td><p class="first"><strong>A.60</strong>: Using a pointer to memory that does not belong to the application, in an attempt to make the cryptoprocessor read or write memory that is inaccessible to the application.</p>
<p><strong>A.70</strong>: Passing out-of-range values, or incorrectly formatted data, to provoke incorrect behavior in the cryptoprocessor.</p>
<p><strong>A.61</strong>: Providing invalid buffer lengths to cause out-of-bounds read or write access within the cryptoprocessor.</p>
<p class="last"><strong>A.62</strong>: Call API functions in an invalid sequence to provoke incorrect operation of the cryptoprocessor.</p>
</td>
</tr>
<tr class="row-odd"><td>T.5</td>
<td>Direct access to cryptoprocessor state</td>
<td>G.3 G.4</td>
<td>M.2 or M.3</td>
<td><p class="first"><strong>A.C7</strong>: Without a cryptoprocessor boundary, an attacker can directly access the cryptoprocessor state from an application. See <span><a class="reference internal" href="#fig-dfd-no-isolation"><span class="numref">Figure 19</span></a></span>.</p>
<p class="last"><strong>A.C8</strong>: A misconfigured cryptoprocessor boundary can allow an attacker to directly access the cryptoprocessor state from an Application.</p>
</td>
</tr>
<tr class="row-even"><td>T.6</td>
<td>Access and use another application’s assets</td>
<td>G.1 G.2</td>
<td>M.2 or M.3</td>
<td><p class="first"><strong>A.C9</strong>: Without application boundaries, the cryptoprocessor provides a unified view of the application assets. All keys are accessible to all callers of the PSA Cryptography API. See <span><a class="reference internal" href="#fig-dfd-caller-isolation"><span class="numref">Figure 21</span></a></span>.</p>
<p class="last"><strong>A.C10</strong>: The attacker can spoof the application identity within a caller-isolated implementation to gain access to another application’s assets.</p>
</td>
</tr>
<tr class="row-odd"><td>T.7</td>
<td>Data-dependent timing</td>
<td>G.1 G.3</td>
<td>M.2 or M.3</td>
<td><strong>A.C11</strong> Measuring the time for operations in the cryptoprocessor or the application, and using the differential in results to assist in recovery of the key or plaintext.</td>
</tr>
<tr class="row-even"><td>T.8</td>
<td>Memory manipulation</td>
<td>G.4</td>
<td>M.4</td>
<td><strong>A.19</strong>: Corrupt application or cryptoprocessor state via a fault, causing incorrect operation of the cryptoprocessor.</td>
</tr>
<tr class="row-odd"><td>&#160;</td>
<td>&#160;</td>
<td>&#160;</td>
<td>M.2 or M.3</td>
<td><strong>A.59</strong>: Modifying function parameters in memory, while the cryptoprocessor is accessing the parameter memory, to cause incorrect operation of the cryptoprocessor.</td>
</tr>
<tr class="row-even"><td>T.9</td>
<td>Side channels</td>
<td>G.1 G.3</td>
<td>M.5</td>
<td><strong>A.C12</strong> Taking measurements from physical side-channels during cryptoprocessor operation, and using this data to recover keys or plaintext. For example, using power or EM measurements.</td>
</tr>
<tr class="row-odd"><td>&#160;</td>
<td>&#160;</td>
<td>&#160;</td>
<td>M.2 or M.3</td>
<td><strong>A.C13</strong> Taking measurements from shared-resource side-channels during cryptoprocessor operation, and using this data to recover keys or plaintext. For example, attacks using a shared cache.</td>
</tr>
</tbody>
</table>
</div>
<div class="section" id="risk-assessment">
<span id="id3"></span><h3>Risk assessment</h3>
<p>The risk ratings in <span><a class="reference internal" href="#table-risks"><span class="numref">Table 27</span></a></span> follow a version of the risk assessment scheme in <span><em>NIST Special Publication 800-30 Revision 1: Guide for Conducting Risk Assessments</em> <a class="reference internal" href="../about.html#citation-sp800-30"><span class="cite">[SP800-30]</span></a></span>. Likelihood of an attack and its impact are evaluated independently, and then they are combined to obtain the overall risk of the attack.</p>
<p>The risk assessment is used to prioritize the threats that require mitigation. This helps to identify the mitigations that have the highest priority for implementation. Mitigations are described in <a class="reference internal" href="#mitigations"><span class="secref">Mitigations</span></a> and <a class="reference internal" href="#remediation"><span class="secref">Remediation &amp; residual risk</span></a>.</p>
<p>It is recommended that this assessment is repeated for a specific implementation or product, taking into consideration the Adversarial models that are within scope, and re-evaluating the impact based on the assets at risk.</p>
<table border="1" class="colwidths-given longtable docutils align-right" id="table-risks">
<caption><span class="caption-number">Table 27 </span><span class="caption-text">Risk assessment</span></caption>
<colgroup>
<col width="20%" />
<col width="20%" />
<col width="20%" />
<col width="20%" />
<col width="20%" />
</colgroup>
<thead valign="bottom">
<tr class="row-odd"><th class="head">Adversarial Model <sup>a</sup></th>
<th class="head">Threat/Attack</th>
<th class="head">Likelihood</th>
<th class="head">Impact <sup>b</sup></th>
<th class="head">Risk</th>
</tr>
</thead>
<tbody valign="top">
<tr class="row-even"><td>M.1</td>
<td>T.1</td>
<td>High</td>
<td>Medium</td>
<td>Medium</td>
</tr>
<tr class="row-odd"><td>M.1</td>
<td>T.2</td>
<td>High</td>
<td>Medium</td>
<td>Medium</td>
</tr>
<tr class="row-even"><td>M.2 or M.3</td>
<td>T.3</td>
<td>Medium</td>
<td>High</td>
<td>Medium</td>
</tr>
<tr class="row-odd"><td>M.2 or M.3</td>
<td>T.4</td>
<td>High</td>
<td>Medium</td>
<td>Medium</td>
</tr>
<tr class="row-even"><td>M.2 or M.3</td>
<td>T.5</td>
<td>High</td>
<td>Very high</td>
<td>Very high</td>
</tr>
<tr class="row-odd"><td>M.2 or M.3</td>
<td>T.6</td>
<td>High</td>
<td>High</td>
<td>High</td>
</tr>
<tr class="row-even"><td>M.2 or M.3</td>
<td>T.7</td>
<td>Medium</td>
<td>Medium</td>
<td>Medium</td>
</tr>
<tr class="row-odd"><td>M.2 or M.3</td>
<td>T.8/A.59</td>
<td>Medium</td>
<td>Medium</td>
<td>Medium</td>
</tr>
<tr class="row-even"><td>M.4</td>
<td>T.8/A.19</td>
<td>Low</td>
<td>Medium</td>
<td>Low</td>
</tr>
<tr class="row-odd"><td>M.5</td>
<td>T.9/A.C12</td>
<td>Low</td>
<td>High</td>
<td>Medium</td>
</tr>
<tr class="row-even"><td>M.2 or M.3</td>
<td>T.9/A.C12</td>
<td>Medium</td>
<td>High</td>
<td>Medium</td>
</tr>
</tbody>
</table>
<ol class="loweralpha simple">
<li>This repeats the association in <span><a class="reference internal" href="#table-threats"><span class="numref">Table 26</span></a></span> between an Adversarial model and the Threats that it enables. This aids filtering of the assessment based on the models that are in scope for a specific implementation.</li>
<li>The impact of an attack is dependent on the impact of the disclosure or modification of the application data that is cryptographically protected. This is ultimately determined by the requirements and risk assessment for the product which is using this API. <span><a class="reference internal" href="#table-risks"><span class="numref">Table 27</span></a></span> allocates the impact as follows:<ul>
<li>‘Medium’ if unspecified cryptoprocessor state or application data assets are affected.</li>
<li>‘High’ if an application’s cryptographic assets are affected.</li>
<li>‘Very High’ if all cryptoprocessor assets are affected.</li>
</ul>
</li>
</ol>
</div>
</div>
<div class="section" id="mitigations">
<span id="id4"></span><h2>Mitigations</h2>
<div class="section" id="objectives">
<h3>Objectives</h3>
<p>The objectives in <span><a class="reference internal" href="#table-objectives"><span class="numref">Table 28</span></a></span> are a high-level description of what the design must achieve in order to mitigate the threats. Detailed requirements that describe how the API or cryptoprocessor implementation can deliver the objectives are provided in <a class="reference internal" href="#mitigation-requirements"><span class="secref">Requirements</span></a> and <a class="reference internal" href="#remediation"><span class="secref">Remediation &amp; residual risk</span></a>.</p>
<table border="1" class="colwidths-given longtable docutils align-right" id="table-objectives">
<caption><span class="caption-number">Table 28 </span><span class="caption-text">Mitigation objectives</span></caption>
<colgroup>
<col width="8%" />
<col width="54%" />
<col width="38%" />
</colgroup>
<thead valign="bottom">
<tr class="row-odd"><th class="head">Id</th>
<th class="head">Description</th>
<th class="head">Threats addressed</th>
</tr>
</thead>
<tbody valign="top">
<tr class="row-even"><td>O.1</td>
<td>Hide keys from the application</td>
<td>&#160;</td>
</tr>
<tr class="row-odd"><td>&#160;</td>
<td>Keys are never directly manipulated by application software. Instead keys are referred to by handle, removing the need to deal with sensitive key material inside applications. This form of API is also suitable for secure elements, based on tamper-resistant hardware, that never reveal cryptographic keys.</td>
<td><p class="first">T.1 T.2 T.3 — see <a class="reference internal" href="../overview/goals.html#keystore"><span class="secref">A keystore interface</span></a>.</p>
<p class="last">T.5 T.6 — to mitigate T.5 and T.6, the implementation must provide some form of isolation. See <a class="reference internal" href="../overview/goals.html#isolation"><span class="secref">Optional isolation</span></a>.</p>
</td>
</tr>
<tr class="row-even"><td>O.2</td>
<td>Limit key usage</td>
<td>&#160;</td>
</tr>
<tr class="row-odd"><td>&#160;</td>
<td>Associate each key with a policy that limits the use of the key. The policy is defined by the application when the key is created, after which it is immutable.</td>
<td>T.2 T.3 — see <a class="reference internal" href="../api/keys/policy.html#key-policy"><span class="secref">Key policies</span></a>.</td>
</tr>
<tr class="row-even"><td>O.3</td>
<td>Best-practice cryptography</td>
<td>&#160;</td>
</tr>
<tr class="row-odd"><td>&#160;</td>
<td>An application developer-oriented API to achieve practical cryptography: the PSA Cryptography API offers services that are oriented towards the application of cryptographic methods like encrypt, sign, verify. This enables the implementation to focus on best-practice implementation of the cryptographic primitive, and the application developer on correct selection and use of those primitives.</td>
<td>T.1 T.2 T.7 T.8 — see <a class="reference internal" href="../overview/goals.html#usability"><span class="secref">Ease of use</span></a>.</td>
</tr>
<tr class="row-even"><td>O.4</td>
<td>Algorithm agility</td>
<td>&#160;</td>
</tr>
<tr class="row-odd"><td>&#160;</td>
<td>Cryptographic functions are not tied to a specific cryptographic algorithm. Primitives are designated at run-time. This simplifies updating an application to use a more secure algorithm, and makes it easier to implement dynamic selection of cryptographic algorithms within an application.</td>
<td>T.1 — see <a class="reference internal" href="../overview/goals.html#algorithm-agility"><span class="secref">Choice of algorithms</span></a>.</td>
</tr>
</tbody>
</table>
</div>
<div class="section" id="requirements">
<span id="mitigation-requirements"></span><h3>Requirements</h3>
<p>The design of the API can mitigate, or enable a cryptoprocessor to mitigate, some of the identified attacks. <span><a class="reference internal" href="#tab-security-requirements"><span class="numref">Table 29</span></a></span> describes these mitigations. Mitigations that are delegated to the cryptoprocessor or application are described in <a class="reference internal" href="#remediation"><span class="secref">Remediation &amp; residual risk</span></a>.</p>
<table border="1" class="colwidths-given longtable docutils align-right" id="tab-security-requirements">
<caption><span class="caption-number">Table 29 </span><span class="caption-text">Security requirements</span></caption>
<colgroup>
<col width="8%" />
<col width="31%" />
<col width="31%" />
<col width="31%" />
</colgroup>
<thead valign="bottom">
<tr class="row-odd"><th class="head">Id</th>
<th class="head">Description</th>
<th class="head">API impact</th>
<th class="head">Threats/attacks addressed</th>
</tr>
</thead>
<tbody valign="top">
<tr class="row-even"><td>SR.1 (O.1)</td>
<td>Key values are not exposed by the API, except when importing or exporting a key.</td>
<td>The full key policy must be provided at the time a key is created. See <a class="reference internal" href="../overview/functionality.html#key-overview"><span class="secref">Key management</span></a>.</td>
<td>T.3/A.C5 — key values are hidden by the API.</td>
</tr>
<tr class="row-odd"><td>SR.2 (O.2)</td>
<td>The policy for a key must be set when the key is created, and be immutable afterward.</td>
<td>The full key policy must be provided at the time a key is created. See <a class="reference internal" href="../api/keys/attributes.html#c.psa_key_attributes_t" title="psa_key_attributes_t"><code class="xref any c c-type docutils literal"><span class="pre">psa_key_attributes_t</span></code></a>.</td>
<td><p class="first">T.3/A.C5 — once created, the key usage permissions cannot be changed to permit export.</p>
<p class="last">T.2/A.C4— once created, a key cannot be repurposed by changing its policy.</p>
</td>
</tr>
<tr class="row-even"><td>SR.3 (O.2)</td>
<td>The key policy must control the algorithms that the key can be used with, and the functions of the API that the key can be used with.</td>
<td>The key policy must include usage permissions, and permitted-algorithm attributes. See <a class="reference internal" href="../api/keys/policy.html#key-policy"><span class="secref">Key policies</span></a>.</td>
<td>T.2/A.C4 — a key cannot be reused with different algorithms.</td>
</tr>
<tr class="row-odd"><td>SR.4 (O.1)</td>
<td>Key export must be controlled by the key policy.</td>
<td>See <a class="reference internal" href="../api/keys/policy.html#c.PSA_KEY_USAGE_EXPORT" title="PSA_KEY_USAGE_EXPORT"><code class="xref any c c-macro docutils literal"><span class="pre">PSA_KEY_USAGE_EXPORT</span></code></a>.</td>
<td>T.3/A.C5 — a key can only be extracted from the cryptoprocessor if explicitly permitted by the key creator.</td>
</tr>
<tr class="row-even"><td>SR.5 (O.1)</td>
<td>The policy of a copied key must not provide rights that are not permitted by the original key policy.</td>
<td>See <a class="reference internal" href="../api/keys/management.html#c.psa_copy_key" title="psa_copy_key"><code class="xref any c c-func docutils literal"><span class="pre">psa_copy_key()</span></code></a>.</td>
<td><p class="first">T.3/A.C5 — a copy of a key cannot be exported if the original could not be exported.</p>
<p class="last">T.3/A.C4 — a copy of a key cannot be used in different algorithm to the original.</p>
</td>
</tr>
<tr class="row-odd"><td>SR.6 (O.3)</td>
<td>Unless explicitly required by the use case, the API must not define cryptographic algorithms with known security weaknesses. If possible, deprecated algorithms should not be included.</td>
<td>Algorithm inclusion is based on use cases. Warnings are provided for algorithms and operations with known security weaknesses, and recommendations made to use alternative algorithms.</td>
<td>T.1/A.C1 A.C2 A.C3</td>
</tr>
<tr class="row-even"><td>SR.7 (O.4)</td>
<td>The API design must make it easy to change to a different algorithm of the same type.</td>
<td>Cryptographic operation functions select the specific algorithm based on parameters passed at runtime. See <a class="reference internal" href="../api/keys/types.html#key-types"><span class="secref">Key types</span></a> and <a class="reference internal" href="../api/ops/algorithms.html#algorithms"><span class="secref">Algorithms</span></a>.</td>
<td>T.1/A.C1 A.C2 A.C3</td>
</tr>
<tr class="row-odd"><td>SR.8 (O.1)</td>
<td>Key derivation functions that expose part of the key value, or make part of the key value easily recoverable, must not be provided in the API.</td>
<td>&#160;</td>
<td>T.3/A.C6</td>
</tr>
<tr class="row-even"><td>SR.9 (O.3)</td>
<td>Constant values defined by the API must be designed to resist bit faults.</td>
<td><p class="first">Key type values explicitly consider single-bit faults, see <a class="reference internal" href="encodings.html#key-type-encoding"><span class="secref">Key type encoding</span></a>. <sup>a</sup></p>
<p class="last">Success and error status codes differ by multiple bits, see <a class="reference internal" href="../api/library/status.html#status-codes"><span class="secref">PSA status codes</span></a>. <sup>b</sup></p>
</td>
<td>T.8/A.19 — enablement only, mitigation is delegated to the implementation.</td>
</tr>
<tr class="row-odd"><td>SR.10 (O.3)</td>
<td>The API design must permit the implementation of operations with data-independent timing.</td>
<td>Provision of comparison functions for MAC, hash and key derivation operations.</td>
<td>T.7/A.C11 — enablement only, mitigation is delegated to the implementation.</td>
</tr>
<tr class="row-even"><td>SR.11 (O.3)</td>
<td>Specify behavior for memory shared between the application and cryptoprocessor, including where multiple parameters overlap.</td>
<td>Standardize the result when parameters overlap, see <a class="reference internal" href="../overview/conventions.html#buffer-overlap"><span class="secref">Overlap between parameters</span></a>.</td>
<td>T.8/A.59 — enablement only, mitigation is delegated to the implementation.</td>
</tr>
<tr class="row-odd"><td>SR.12 (O.1) (O.2)</td>
<td>The API must permit the implementation to isolate the cryptoprocessor, to prevent access to keys without using the API.</td>
<td>No use of shared memory between application and cryptoprocessor, except as function parameters.</td>
<td>T.5/A.C7 — enablement only, mitigation is delegated to the implementation.</td>
</tr>
<tr class="row-even"><td>SR.13 (O.3)</td>
<td>The API design must permit the implementation of operations using mitigation techniques that resist side-channel attacks.</td>
<td><p class="first">Operations that use random blinding to resist side-channel attacks, can return RNG-specific error codes.</p>
<p class="last">See also SR.12, which enables the cryptoprocessor to be fully isolated, and implemented within a separate security processor.</p>
</td>
<td>T.9 — enablement only, mitigation is delegated to the implementation.</td>
</tr>
</tbody>
</table>
<ol class="loweralpha simple">
<li>Limited resistance to bit faults is still valuable in systems where memory may be susceptible to single-bit flip attacks, for example, Rowhammer on some types of DRAM.</li>
<li>Unlike key type values, algorithm identifiers used in cryptographic operations are verified against a the permitted-algorithm in the key policy. This provides a mitigation for a bit fault in an algorithm identifier value, without requiring error detection within the algorithm identifier itself.</li>
</ol>
</div>
</div>
<div class="section" id="remediation-residual-risk">
<span id="remediation"></span><h2>Remediation &amp; residual risk</h2>
<div class="section" id="implementation-remediations">
<h3>Implementation remediations</h3>
<p><span><a class="reference internal" href="#tab-remediation"><span class="numref">Table 30</span></a></span> includes all recommended remediations for an implementation, assuming the full adversarial model described in <a class="reference internal" href="#adversarial-models"><span class="secref">Adversarial models</span></a>. When an implementation has a subset of the adversarial models, then individual remediations can be excluded from an implementation, if the associated threat is not relevant for that implementation.</p>
<table border="1" class="colwidths-given longtable docutils align-right" id="tab-remediation">
<caption><span class="caption-number">Table 30 </span><span class="caption-text">Implementation remediations</span></caption>
<colgroup>
<col width="8%" />
<col width="31%" />
<col width="62%" />
</colgroup>
<thead valign="bottom">
<tr class="row-odd"><th class="head">Id</th>
<th class="head">Identified gap</th>
<th class="head">Suggested remediation</th>
</tr>
</thead>
<tbody valign="top">
<tr class="row-even"><td>R.1 (O.1) (O.3)</td>
<td>T.5 — direct access to cryptoprocessor state.</td>
<td>The cryptoprocessor implementation provides <a class="reference internal" href="../about.html#term-cryptoprocessor-isolation"><span class="term">cryptoprocessor isolation</span></a> or <a class="reference internal" href="../about.html#term-caller-isolation"><span class="term">caller isolation</span></a>, to isolate the application from the cryptoprocessor state, and from volatile and persistent key material.</td>
</tr>
<tr class="row-odd"><td>R.2 (O.1) (O.3)</td>
<td>T.6 — access and use another application’s assets.</td>
<td><p class="first">The cryptoprocessor implementation provides <a class="reference internal" href="../about.html#term-caller-isolation"><span class="term">caller isolation</span></a>, and maintains separate cryptoprocessor state for each application. Each application must only be able to access its own keys and ongoing operations.</p>
<p class="last">Caller isolation requires that the implementation can securely identify the caller of the PSA Cryptography API.</p>
</td>
</tr>
<tr class="row-even"><td>R.3 (O.3)</td>
<td>T.4/A.60 A.61 — using illegal memory inputs.</td>
<td>The cryptoprocessor implementation validates that memory buffers provided by the application are accessible by the application.</td>
</tr>
<tr class="row-odd"><td>R.4 (O.3)</td>
<td>T.4/A.70 — providing invalid formatted data.</td>
<td>The cryptoprocessor implementation checks that imported key data is valid before use.</td>
</tr>
<tr class="row-even"><td>R.5 (O.3)</td>
<td>T.4/A.62 — call the API in an invalid operation sequence.</td>
<td>The cryptoprocessor implementation enforces the correct sequencing of calls in multi-part operations. See <a class="reference internal" href="../overview/functionality.html#multi-part-operations"><span class="secref">Multi-part operations</span></a>.</td>
</tr>
<tr class="row-odd"><td>R.6 (O.1) (O.3)</td>
<td>T.3/A.C5 A.C6 — indirect key disclosure via the API.</td>
<td>Cryptoprocessor implementation-specific extensions to the API must avoid providing mechanisms that can extract or recover key values, such as trivial key derivation algorithms.</td>
</tr>
<tr class="row-even"><td>R.8 (O.3)</td>
<td>T.8/A.59 — concurrent modification of parameter memory.</td>
<td>The cryptoprocessor implementation treats application memory as untrusted and volatile, typically by not reading the same memory location twice. See <a class="reference internal" href="../overview/conventions.html#stability-of-parameters"><span class="secref">Stability of parameters</span></a>.</td>
</tr>
<tr class="row-odd"><td>R.9 (O.3)</td>
<td>T.2/A.C4 — incorrect cryptographic parameters.</td>
<td>The cryptoprocessor implementation validates the key attributes and other parameters used for a cryptographic operation, to ensure these conform to the API specification and to the specification of the algorithm itself.</td>
</tr>
<tr class="row-even"><td>R.10 (O.3)</td>
<td>T.1/A.C1 A.C2 A.C3 — insecure cryptographic algorithms.</td>
<td>The cryptoprocessor does not support deprecated cryptographic algorithms, unless justified by specific use case requirements.</td>
</tr>
<tr class="row-odd"><td>R.11 (O.3)</td>
<td>T.7/A.C11 — data-independent timing.</td>
<td>The cryptoprocessor implements cryptographic operations with data-independent timing.</td>
</tr>
<tr class="row-even"><td>R.12 (O.3)</td>
<td>T.9 — side-channels.</td>
<td>The cryptoprocessor implements resistance to side-channels.</td>
</tr>
</tbody>
</table>
</div>
<div class="section" id="residual-risk">
<h3>Residual risk</h3>
<p><span><a class="reference internal" href="#tab-residual-risk"><span class="numref">Table 31</span></a></span> describes the remaining risks that cannot be mitigated fully by the API or cryptoprocessor implementation. Responsibility for managing these risks lies with the application developers and system integrators.</p>
<table border="1" class="colwidths-given longtable docutils align-right" id="tab-residual-risk">
<caption><span class="caption-number">Table 31 </span><span class="caption-text">Residual risk</span></caption>
<colgroup>
<col width="8%" />
<col width="31%" />
<col width="62%" />
</colgroup>
<thead valign="bottom">
<tr class="row-odd"><th class="head">Id</th>
<th class="head">Threat/attack</th>
<th class="head">Suggested remediations</th>
</tr>
</thead>
<tbody valign="top">
<tr class="row-even"><td>RR.1</td>
<td>T.1</td>
<td>Selection of appropriately secure protocols, algorithms and key sizes is the responsibility of the application developer.</td>
</tr>
<tr class="row-odd"><td>RR.2</td>
<td>T.5</td>
<td>Correct isolation of the cryptoprocessor is the responsibility of the cryptoprocessor and system implementation.</td>
</tr>
<tr class="row-even"><td>RR.3</td>
<td>T.6</td>
<td>Correct identification of the application client is the responsibility of the cryptoprocessor and system implementation.</td>
</tr>
</tbody>
</table>
</div>
</div>
</div>


          </div>
        </div>
      </div>
      <div class="sphinxsidebar" role="navigation" aria-label="main navigation">
        <div class="sphinxsidebarwrapper"><h3><a href="../index.html"><b>PSA Crypto API</b></a></h3>
IHI 0086<br/>
Non-confidential<br/>
Version 1.1.0
<span style="color: red; font-weight: bold;"></span>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../about.html">About this document</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../overview/intro.html">1. Introduction</a></li>
<li class="toctree-l1"><a class="reference internal" href="../overview/goals.html">2. Design goals</a></li>
<li class="toctree-l1"><a class="reference internal" href="../overview/functionality.html">3. Functionality overview</a></li>
<li class="toctree-l1"><a class="reference internal" href="../overview/sample-arch.html">4. Sample architectures</a></li>
<li class="toctree-l1"><a class="reference internal" href="../overview/conventions.html">5. Library conventions</a></li>
<li class="toctree-l1"><a class="reference internal" href="../overview/implementation.html">6. Implementation considerations</a></li>
<li class="toctree-l1"><a class="reference internal" href="../overview/usage.html">7. Usage considerations</a></li>
<li class="toctree-l1"><a class="reference internal" href="../api/library/index.html">8. Library management reference</a></li>
<li class="toctree-l1"><a class="reference internal" href="../api/keys/index.html">9. Key management reference</a></li>
<li class="toctree-l1"><a class="reference internal" href="../api/ops/index.html">10. Cryptographic operation reference</a></li>
</ul>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="example_header.html">Example header file</a></li>
<li class="toctree-l1"><a class="reference internal" href="encodings.html">Algorithm and key type encoding</a></li>
<li class="toctree-l1"><a class="reference internal" href="specdef_values.html">Example macro implementations</a></li>
<li class="toctree-l1 current"><a class="current reference internal" href="#">Security Risk Assessment</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#architecture">Architecture</a><ul>
<li class="toctree-l3"><a class="reference internal" href="#system-definition">System definition</a></li>
<li class="toctree-l3"><a class="reference internal" href="#assets-and-stakeholders">Assets and stakeholders</a></li>
<li class="toctree-l3"><a class="reference internal" href="#security-goals">Security goals</a></li>
</ul>
</li>
<li class="toctree-l2"><a class="reference internal" href="#threat-model">Threat Model</a><ul>
<li class="toctree-l3"><a class="reference internal" href="#adversarial-models">Adversarial models</a></li>
<li class="toctree-l3"><a class="reference internal" href="#threats-and-attacks">Threats and attacks</a></li>
<li class="toctree-l3"><a class="reference internal" href="#risk-assessment">Risk assessment</a></li>
</ul>
</li>
<li class="toctree-l2"><a class="reference internal" href="#mitigations">Mitigations</a><ul>
<li class="toctree-l3"><a class="reference internal" href="#objectives">Objectives</a></li>
<li class="toctree-l3"><a class="reference internal" href="#requirements">Requirements</a></li>
</ul>
</li>
<li class="toctree-l2"><a class="reference internal" href="#remediation-residual-risk">Remediation &amp; residual risk</a><ul>
<li class="toctree-l3"><a class="reference internal" href="#implementation-remediations">Implementation remediations</a></li>
<li class="toctree-l3"><a class="reference internal" href="#residual-risk">Residual risk</a></li>
</ul>
</li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="history.html">Changes to the API</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../psa_c-identifiers.html">Index of API elements</a></li>
</ul>
<div id="searchbox" style="display: none" role="search">
  <h3>Quick search</h3>
    <form class="search" action="../search.html" method="get">
      <div><input type="text" name="q" /></div>
      <div><input type="submit" value="Go" /></div>
      <input type="hidden" name="check_keywords" value="yes" />
      <input type="hidden" name="area" value="default" />
    </form>
</div>
<script type="text/javascript">$('#searchbox').show(0);</script>
        </div>
      </div>
      <div class="clearer"></div>
    </div>
    <div class="footer">
      &copy; 2018-2022, Arm Limited or its affiliates. All rights reserved.
      
      |
      Powered by <a href="http://sphinx-doc.org/">Sphinx 1.6.7</a>
      &amp; <a href="https://github.com/bitprophet/alabaster">Alabaster 0.7.8</a>
      
    </div>

    

    
  </body>
</html>